home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 16 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.5 KB
  1. From: Julian F. Reschke <julian@GINA.UNI-MUENSTER.DE>
  2. Subject: libraries
  3. Date: Sun, 17 Jan 93 23:01:42 MET DST
  4.  
  5. Hi all!
  6.  
  7. Some thoughts about header files, libraries and so on.
  8.  
  9.  
  10. (1) setmode
  11.  
  12. The new jpeg source (V4) has a switch for libraries with setmode(). This
  13. function changes the mode of an open file, and there's no other 'good'
  14. method, because ANSI has forgotten the problem of binary I/O on
  15. stdin/stdout. Example:
  16.  
  17. #ifdef USE_SETMODE
  18. #include <fcntl.h>        /* to declare setmode() */
  19. #endif
  20.  
  21. ...
  22.  
  23. #ifdef USE_SETMODE        /* need to hack file mode? */
  24.   setmode(fileno(stdin), O_BINARY);
  25.   setmode(fileno(stdout), O_BINARY);
  26. #endif
  27.  
  28. Please add that to the libs (I already spoke with Peter Sollich, so that
  29. he can add the same function to the standard Pure C libraries).
  30.  
  31.  
  32. (2) XBIOS function names
  33.  
  34. I was going to repeat that all XBIOS calls should start with uppercase
  35. characters... but now I see in falcon.h, that setmode() has been
  36. renamed to Vsetmode()... :-)
  37.  
  38.  
  39. (3) stdin binary?
  40.  
  41. entroy wrote in his mail concerning library PL26:
  42. >Patchlevel 26 is likely to be the last patchlevel with TOS style (CR-LF
  43. >pair) carriage control.  Unless I hear some really good arguments against
  44. >doing so, I'm going to convert everything to UNIX style (LF) carriage
  45. >control.  Many of the programs I use get really confused with TOS style
  46. >files.  Also, J. Bammi's GCC libs use the UNIX style, so converting
  47. >everything will make sychronizing the two libraries easier.
  48.  
  49. Here we go. Most of my text editors use CR/LF. Probably all GEM programs.
  50. Libraries that can't read or write these files are useless for me. By
  51. now, there's no ANSI method to do binary I/O on stdin or stdout, that's
  52. why I propose to implement setmode() (see 1.). And for all properly
  53. written programs, this is enough.
  54.  
  55. BTW: I have a lot of GEM programs which get confused by files *without*
  56. carriage returns :-) And for *those* programs, I don't have the source
  57. code (as opposed to most UNIX stuff).
  58.  
  59.  
  60. (4) Operating system header files
  61.  
  62. In the last days, I've tried to port a program from PureC with Pure's
  63. libraries to gcc with MiNT libs.
  64.  
  65. Unfortunately, some system functions have conflicting prototypes, and
  66. most of the OS structures are defined differently. In addition, practically
  67. *all* BIOS/XBIOS/GEMDOS structures are defined differently. And finally,
  68. even the *names* of the include files are different.
  69.  
  70. Obviously, there's no way to change that without breaking existing
  71. source code. My proposal: let's make a new standard (together with
  72. Eric Smith, Pure Software and the Lattice guys). What we need:
  73.  
  74. (1) Standard prototypes for *all* operating system functions (perhaps
  75.     we'll need a standard compiler.h for sizeof(int) and cdecl etc, too).
  76.  
  77. (2) Standard definitions of operating system structures. In theory, this
  78.     should always be what Atari's documentation says (I *think* that
  79.     this is what Pure does). In particular, I don't understand why
  80.     the MiNT libs use _DTA instead of DTA and so on.
  81.  
  82. (3) A standard location for these files. Let's define a new subdirectory
  83.     in include\, so that we can #include <tos/mint.h> or <tos/vdi.h>
  84.     This would allow each of us to support 'old' programs.
  85.  
  86. All the other library stuff should be defined clear enough by ANSI (C)
  87. or POSIX 1003.1. Of course, I am willing to do a part of the job.
  88. Comments?
  89.  
  90.  
  91. -- 
  92. ________________ cut here _________________________
  93. Julian F. Reschke, Hensenstr. 142, D-W4400 Muenster
  94.   eMail: julian@math.uni-muenster.de, jr@ms.maus.de
  95. ________ correct me if I'm wrong __________________
  96.